Subject: OSI Network Management an APPN

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 29 Jul 1994 13:14:00 -0400

The core of our network management system is based on OSI network management.
I am having difficulty mapping one part of that structure to the APPN NOF.

In OSI network management if you wish to deny further access to a resource
you issue a Lock.  This is then reversed by an Unlock.  I found this
terminology rather confusing at first.  This has nothing to do with security,
as the "lock" analogy would imply.  Lock maps to a resource disable,
deactivate, vary inactive, or, for the most part, to the STOP_x NOF verbs.

I have no problem with Lock applied to DLCs, Ports, or Link Stations.  They
all map to STOP_x, and Unlock maps to START_x.

I do have a problem with the natural requirement to be able to issue a Lock
or Unlock to the APPN node as a whole, because STOP_NODE does not simply shut
down processing and wait for a reversing START_NODE.  STOP_NODE actually
results in the destruction of the entire process hierarchy and can only be
reversed by repeating the whole sequence of DEFINE_Xs which brought the node
up in the first place.

I therefore find myself needing a NOF command which issues STOP_DLC to all
DLCs (hierarchically stopping all Ports and LSs), and UNBINDs all internal
sessions, but does not throw away the accumulated knowledge of the
configuration of the node.  I then need a NOF command to restore the state of
all DLCs, Ports, and LSs to where they were before the node was locked, and
reactivates the sessions.

Part of the problem seems to be the original assymetry in defining the node.
Where a DLC, for example, is first defined by a DEFINE_DLC and subsequently
can be explicitly STARTed or STOPped, and finally removed from the
configuration by a DELETE_DLC, but the Node as a whole is not created by a
DEFINE_NODE and eventually removed from the configuration by a DELETE_NODE,
with START_NODE and STOP_NODE merely altering the status of the node.

My artistic side rebels at this assymetry.  My client support side rebels at
the lack of quality which not delivering what the customer expects will
appear as.  My developer side rebels at the additional cost and effort that I
must go through to provide a symmetrical interface to the customer.

I am unfortunately confident that the rest of the industry does not find this
assymetrical architecture as offensive as I do.  However I would like to see
the START_NODE NOF verb architecturally split into a DEFINE_NODE and a
START_NODE, and the STOP_NODE verb split into a STOP_NODE and a DELETE_NODE.